Scroll to navigation

SSSD-SECRETS(5) Формати файлів та правила SSSD-SECRETS(5)

NAME

sssd-secrets - Відповідач реєстраційних даних SSSD

ОПИС

На цій сторінці довідника описано налаштування засобу надання відповідей Secrets для sssd(8). Щоб дізнатися більше про синтаксис налаштування, зверніться до розділу «ФОРМАТ ФАЙЛІВ» сторінки довідника sssd.conf(5).

У багатьох програмах системи або користувача існує потреба у збереженні конфіденційних даних, зокрема паролів і ключів до служб, та зручній роботі з цими даними. Простим способом вирішення цієї проблеми є вбудовування цих “реєстраційних даних” до файлів налаштувань. Втім, це призводить до потенційного розширення доступу до конфіденційних даних через резервні копії, системи керування налаштуваннями, та загалом робить захист даних важчим.

Проєкт custodia[1] було створено для урегулювання цієї проблеми у хмароподібних середовищах, але нам ця ідея здалася вартою уваги навіть на рівні окремої ізольованої системи. Як служба захисту, SSSD є ідеальним місцем для реалізації такої можливості з доступом до відповідного програмного інтерфейсу через сокети UNIX. Така реалізація уможливлює використання локальних викликів і належну маршрутизацію до локального або віддаленого сховища ключів, зокрема сховища IPA, для зберігання, депонування і відновлення даних.

Записи реєстраційних даних є простими парами ключ-значення. Реєстраційні дані кожного з користувачів співвідносяться із його простором назв на основі ідентифікатора користувача. Це означає, що реєстраційні дані одного користувача ніколи не потраплять до іншого. Реєстраційні дані зберігаються у “контейнерах”, які можна вкладати один у одного.

Оскільки відповідач реєстраційних даних може використовуватися ззовні для зберігання загальних реєстраційних даних, як це описано у решті цієї сторінки підручника, і всередині іншими компонентами SSSD для зберігання власних реєстраційних даних, можна налаштувати деякі параметри, зокрема квоти для окремих записів “hive” у підрозділі налаштувань із назвою відповідного рою. Підтримувані у поточній версії рої:

secrets

записи реєстраційних даних для загального використання

kcm

використовується службою sssd-kcm(8).

КОРИСТУВАННЯ ВІДПОВІДАЧЕМ РЕЄСТРАЦІЙНИХ ДАНИХ

Сокет UNIX, на якому відповідач SSSD очікує на дані, розташовано у /var/run/secrets.socket.

Відповідач для реєстраційних даних активується за допомогою сокетів systemd(1). На відміну від інших відповідачів SSSD, його не можна запустити додаванням рядка “secrets” до інструкції “service”. Модуль сокета systemd називається “sssd-secrets.socket”, а відповідний файл служби має назву “sssd-secrets.service”. Щоб службу можна було активувати за допомогою сокета, слід увімкнути і задіяти сокет, а потім увімкнути службу:

systemctl start sssd-secrets.socket
systemctl enable sssd-secrets.socket
systemctl enable sssd-secrets.service

Будь ласка, зауважте, що відповідні налаштування модулів вже могло бути виконано засобами вашого дистрибутива.

ПАРАМЕТРИ НАЛАШТУВАННЯ

Відповідачу реєстраційних даних можна передавати типові параметри відповідача SSSD, зокрема “debug_level” та “fd_limit”. Із повним списком параметрів можна ознайомитися на сторінці підручника sssd.conf(5). Крім того, передбачено декілька специфічних для реєстраційних даних параметрів.

Відповідач реєстраційних даних налаштовується за допомогою загального розділу “[secrets]” і необов'язкових розділів “[secrets/users/$uid]” для окремих користувачів у sssd.conf. Будь ласка, зауважте, що деякі параметра, зокрема тип постачальника даних, можна вказати лише у підрозділах окремих користувачів.

provider (рядок)

Цей параметр визначає, де слід зберігати реєстраційні дані. Відповідач реєстраційних даних може налаштувати підрозділи для окремих користувачів (наприклад, “[secrets/users/123]” — див. нижню частину цієї сторінки підручників, де наведено повний приклад використання Custodia для окремого користувача), які визначатимуть, яке сховище відповідача зберігатиме дані певного користувача. Підрозділи окремих користувачів мають містити усі параметри відповідного засобу надання даних користувача. Будь ласка, зауважте, що у поточній версії загальний постачальних даних з завжди локальним, а проміжного постачальника можна вказати лише для окремого користувача у відповідному розділі. Передбачено підтримку таких відповідачів:

local

Реєстраційні дані зберігаються у локальній базі даних, зашифровані, разом із іншими даними, за допомогою основного ключа. Для локального засобу надання даних у поточній версії не передбачено жодних додаткових параметрів.

proxy

Відповідач реєстраційних даних переспрямовує запити до сервера Custodia. Для засобу надання даних «proxy» передбачено декілька додаткових параметрів (див. нижче).

Типове значення: local

Наведені нижче параметри стосуються лише записів реєстраційних даних “hive” і тому їх слід встановлювати у підрозділах окремих роїв. Встановлення значення параметра 0 означає «без обмежень».

containers_nest_level (ціле значення)

Цей параметр визначає максимальну дозволену кількість вкладених контейнерів.

Типове значення: 4

max_secrets (ціле значення)

Цей параметр визначає максимальну кількість записів реєстраційних даних, які можна зберігати у рою.

Типове значення: 1024 (рій реєстраційних даних), 256 (рій kcm)

max_uid_secrets (ціле число)

Цей параметр визначає максимальну кількість записів реєстраційних даних, які можна зберігати окремо для різних UID у рою.

Типове значення: 256 (рій реєстраційних даних), 64 (рій kcm)

max_payload_size (ціле значення)

Цей параметри визначає максимальний об'єм даних для реєстраційного запису у кілобайтах.

Типове значення: 16 (рій реєстраційних даних), 65536 (64 МіБ) (рій kcm)

Наприклад, щоб встановити різні квоти для роїв “secrets” та “kcm”, скористайтеся такими рядками:

[secrets/secrets]
max_payload_size = 128
[secrets/kcm]
max_payload_size = 256

Вказані нижче параметри стосуються лише конфігурацій, у яких використовується засіб надання даних “proxy”.

proxy_url (рядок)

Адреса, за якою очікуватиме на дані сервер Custodia. У поточній версії передбачено підтримку протоколів http і https.

Формат адреси має відповідати формату, що визначається RFC 2732:

http[s]://<вузол>[:порт]

Приклад: http://localhost:8080

auth_type (рядок)

Спосіб розпізнавання сервером Custodia. Передбачено підтримку таких способів розпізнавання:

basic_auth

Виконати розпізнавання на основі імені користувача і пароля, які визначено параметрами “username” і “password”.

header

Виконати розпізнавання за допомогою значення заголовка HTTP, як його визначено у параметрах налаштування “auth_header_name” і “auth_header_value”.

auth_header_name (рядок)

Якщо встановлено, відповідач реєстраційних даних додаватиме заголовок із цією назвою до запиту HTTP разом із значенням, яке визначається параметром налаштування “auth_header_value”.

Приклад: MYSECRETNAME

auth_header_value (рядок)

Значення, яке sssd-secrets має використовувати для “auth_header_name”.

Приклад: mysecret

forward_headers (список рядків)

Список заголовків HTTP, які слід переспрямувати до сервера Custodia разом із запитом.

Типове значення: not set

verify_peer (булеве значення)

Визначає, чи слід перевіряти сертифікат вузла і чи слід вважати його чинним, якщо для засобу надання даних проксі використано протокол HTTPS.

Типове значення: true

verify_host (булеве значення)

Визначає, чи має назва вузла збігатися із назвою вузла у його сертифікаті, якщо для засобу надання даних проксі використано протокол HTTPS.

Типове значення: true

capath (рядок)

Шлях до каталогу, у якому зберігаються сертифікати служб сертифікації. Якщо для цього параметра не встановлено значення, використовуватиметься загальносистемний типовий шлях.

Типове значення: not set

cacert (рядок)

Шлях до файла, у якому міститься сертифікат служби сертифікації сервера. Якщо для цього параметра не встановлено значення, програма шукатиме сертифікат CA у “capath”.

Типове значення: not set

cert (рядок)

Шлях до файла, що містить клієнтський сертифікат, якщо такий потрібен для сервера. Цей файл може також містити закритий ключ. Закритий ключ можна також зберігати у файлі, назву якого встановлено за допомогою параметра “key”.

Типове значення: not set

key (рядок)

Шлях до файла, у якому міститься закритий ключ клієнта.

Типове значення: not set

КОРИСТУВАННЯ API REST

У цьому розділі наведено список доступних команд та приклади користування із використанням програми curl(1). Усі запити до засобу надання даних проксі мають встановлювати для заголовка Content Type значення “application/json”. Крім того, для локального засобу надання даних передбачено підтримку встановлення для Content Type значення “application/octet-stream”. Реєстраційні дані, збережені із запитами, де встановлено значення заголовка Content Type “application/octet-stream”, є даними у кодуванні base64 у сховищі, які розшифровуються під час отримання, тому не можна зберігати реєстраційні дані із одним значенням Content Type і отримувати з іншим. Адреса реєстраційних даних має починатися з /secrets/.

Отримання списку реєстраційних даних

Щоб отримати список доступних реєстраційних даних, надішліть запит HTTP GET із кінцевою навскісною рискою у шляху до контейнера.

Приклад:

curl -H "Content-Type: application/json" \

--unix-socket /var/run/secrets.socket \
-XGET http://localhost/secrets/

Отримання реєстраційних даних

Щоб прочитати значення окремого запису реєстраційних даних, надішліть запит HTTP GET без кінцевої навскісної риски. Остання частина адреси вважатиметься назвою запису реєстраційних даних.

Приклади:

curl -H "Content-Type: application/json" \

--unix-socket /var/run/secrets.socket \
-XGET http://localhost/secrets/foo

curl -H "Content-Type: application/octet-stream" \

--unix-socket /var/run/secrets.socket \
-XGET http://localhost/secrets/bar

Встановлення реєстраційних даних

Щоб встановити запис реєстраційних даних з використанням типу “application/json”, надішліть запит HTTP PUT із даними JSON, які включатимуть тип і значення. Тип (type) має бути встановлено у значення "simple", а значення (value) має містити дані реєстраційного запису. Якщо запис із вказаною назвою вже існує, відповіддю буде повідомлення про помилку 409 HTTP.

Тип “application/json” просто надсилає реєстраційний ключ як вміст повідомлення.

У наведеному нижче прикладі ми встановлюємо для реєстраційних даних із назвою «foo» значення «foosecret», а для реєстраційних даних із назвою «bar» — значення «barsecret», використовуючи різні значення Content Type.

curl -H "Content-Type: application/json" \

--unix-socket /var/run/secrets.socket \
-XPUT http://localhost/secrets/foo \
-d'{"type":"simple","value":"foosecret"}'

curl -H "Content-Type: application/octet-stream" \

--unix-socket /var/run/secrets.socket \
-XPUT http://localhost/secrets/bar \
-d'barsecret'

Створення контейнера

Контейнери надають додатковий простір назв для реєстраційних даних цього користувача. Для створення контейнера надішліть запит HTTP POST, чи я адреса завершуватиметься назвою контейнера. Будь ласка, зауважте, що адреса має завершуватися символом навскісної риски.

У наступному прикладі створюємо контейнер із назвою «mycontainer»:

curl -H "Content-Type: application/json" \

--unix-socket /var/run/secrets.socket \
-XPOST http://localhost/secrets/mycontainer/

Щоб працювати із записами реєстраційних даних у цьому контейнері, просто вкладіть записи реєстраційних даних до шляху контейнера:

Вилучення реєстраційних даних або контейнера

Щоб вилучити запис реєстраційних даних або контейнер, надішліть запит HTTP DELETE із шляхом до запису реєстраційних даних або до контейнера.

У наведеному нижче прикладі ми вилучимо реєстраційні дані для запису «foo».

curl -H "Content-Type: application/json" \

--unix-socket /var/run/secrets.socket \
-XDELETE http://localhost/secrets/foo

ПРИКЛАД НАЛАШТОВУВАННЯ МОДУЛІВ НАДАННЯ ДАНИХ CUSTODIA І ПРОКСІ

Для тестування засобу надання даних «proxy» вам слід налаштувати проксі-передавання на сервер Custodia. Будь ласка, завжди користуйтеся документацією до Custodia, оскільки інструкції налаштовування у різних версіях Custodia можуть бути різними.

Ці налаштування визначають для сервера Custodia адресу очікування даних http://localhost:8080, дозволяють будь-кому із заголовком із назвою MYSECRETNAME, який встановлено у значення mysecretkey, обмін даними із сервером Custodia. Запишіть ці дані до файла (наприклад, custodia.conf):

[global]
server_version = "Secret/0.0.7"
server_url = http://localhost:8080/
auditlog = /var/log/custodia.log
debug = True
[store:simple]
handler = custodia.store.sqlite.SqliteStore
dburi = /var/lib/custodia.db
table = secrets
[auth:header]
handler = custodia.httpd.authenticators.SimpleHeaderAuth
header = MYSECRETNAME
value = mysecretkey
[authz:paths]
handler = custodia.httpd.authorizers.SimplePathAuthz
paths = /secrets
[/]
handler = custodia.root.Root
store = simple

Далі, віддайте команду custodia, вказавши файл налаштувань у параметрі командного рядка.

Будь ласка, зверніть увагу на те, що у поточній версії неможливо на загальному рівні переспрямовувати усі запити до екземпляра Custodia. Замість цього слід визначати підрозділи для окремих ідентифікаторів користувачів, які переспрямовуватимуть запити до Custodia. У наведеному нижче прикладі проілюстровано конфігурацію, за якої запити користувача із UID 123 переспрямовуватимуться до Custodia, а запити усіх інших користувачів оброблятимуться локальним засобом надання даних.

[secrets]
[secrets/users/123]
provider = proxy
proxy_url = http://localhost:8080/secrets/
auth_type = header
auth_header_name = MYSECRETNAME
auth_header_value = mysecretkey

AUTHORS

Основна гілка розробки SSSD — https://pagure.io/SSSD/sssd/

NOTES

1.
custodia
01/23/2024 SSSD